Network Address Translators (NATs) are used to interconnect a private network consisting of unregistered Internet Protocol (IP) addresses with a global IP network using a limited number of registered IP addresses. NATs are also used to avoid address renumbering in a private network when topology outside the private network changes for variety of reasons, such as customers changing providers, company backbones being reorganized, or providers merging or splitting. In addition, there are many other applications of NAT operation.
Basic Network Address Translation or Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ports are translated into a single network address and TCP/UDP ports. Together, both these operations are referred to as traditional NAT.
NAT operation is asymmetrical with respect to the two Networks with which the NAT interfaces. In general, packets originating in the private network (“inside”) are allowed to be sent to any address in the other network (“outside”). When the first packet of such a packet flow traverses the NAT, a NAT bind will be created, and the source IP address and port of the packet will be changed to reflect the NAT bind. Thus, when the packet arrives at its destination, it will appear to have come from a different source (i.e. from the NAT device). All subsequent packets of the flow will be modified in the same way. In contrast, packets originating from the outside network can not be routed to a host in the inside network, unless a NAT bind has previously been created in the NAT device. In such a case, the packets will have to be addressed to the IP address and port of the NAT bind on the NAT device. Upon receipt of the packets, the NAT device will translate the destination address and port into the proper inside address and port, and forward the packets on to their inside destination. Because of this asymmetry, hosts in the “inside” network are said to be “behind the NAT”.
NATs are further classified based on the rules used to create NAT binds. NATs which create a unique bind for unique source and destination IP addresses and ports are known as Symmetric. NATs which create a unique bind for a unique source addess and port only (i.e. for any destination) are known as Cone.
Unless mentioned otherwise, the term NAT, as used in this specification, will pertain to traditional NAT, namely basic NAT as well as NAPT, and to the devices performing these functions: Network Address Translators, and Network Address and Port Translators.
A number of NAT deployments are currently in use and, naturally, a large number of internet applications work transparently with NATs. However, there are applications that fail if their packets traverse a NAT, such as applications that set-up voice over Internet Protocol (VoIP) calls. VoIP works by the two media endpoints involved in the call exchanging their Session Description Protocol (SDP). The SDP describes the IP address and port where the endpoint expects to receive media for the call, among other things. This exchange of SDP is made possible by the use of a protocol such as SIP, MGCP, H.248 (MEGACO), H.323, NCS or ASPEN, and often involves the help of a Media Gateway Contoller (MGC), typically a softswitch, to broker the exchange. NATs break this model, since the IP address and port embedded in SDP will not reflect the IP address and port modifications made by the NAT. In cases where NATs break the end-to-end functionality of applications, Application Level Gateways (ALGs) are required within the NAT to make application-specific changes to the packet contents so that it reflects the NAT bind, in order to ensure that the application can work through the NAT.
NATs have the potential to interrupt the end-to-end nature of Internet applications, thereby threatening end-to-end security and other end-to-end functions. In addition, NATs have topology restrictions and other constraints on the protocols and applications that run across the NATs. Thus it is important to be able to discover the existence of NATs and their type.
Known techniques for VoIP applications in which an MGC in a public TSP network is controlling a Media Gateway (MG) in a private network, involve determining a NAT's existence and type either through ‘ad hoc’ methods (for example, telephoning the owner of the MG and asking if they are using a NAT and then provisioning this information (by hand) into the MGC prior to bringing the MG into service), or by using a protocol such as Simple Traversal of UDP through NATs (STUN) to discover the presence and type of NATs between the MG and the TSP network. STUN is an Internet Engineering Task Force (IETF) Protocol, defined in the IETF draft “http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-02.txt”, that allows applications to discover the presence and types of NATs in a network, as well as discovering the actual NAPT bind used for a particular media flow. It requires a STUN server in the outside network, and a STUN client in the inside network. By using the STUN protocol between the STUN client and server, the STUN client in the inside network is able to determine NAT existence, type and the actual NAT bind used for a media flow.
The disadvantage of the first technique is that it requires manual human intervention, and is unfeasible as a real solution. The disadvantage of the second technique is that STUN requires the introduction of new network components (STUN clients and servers) in both the TSP and MG networks. In addition, the STUN client must be integrated into the MGs themselves, which means that existing, deployed MGs must be upgraded to contain STUN clients before this technique can be used. Another disadvantage of the second technique is that NAT information is determined by the STUN client behind the NAT (i.e. by an agent in the inside), rather than by the MGC outside of the NAT, although the MGC may need to have knowledge of this information.
Thus there is a need for devising a method of discovering the existence of NATs and their type without requiring any new network elements, without requiring any new protocols or protocol extensions, without requiring any work on the MGs or NATS, without imposing any requirements on the networks outside the TSP network, that will work with existing deployments, using existing protocols.
The present invention aims to address the needs or at least mitigate the problems identified above.